home *** CD-ROM | disk | FTP | other *** search
/ Cream of the Crop 26 / Cream of the Crop 26.iso / os2 / sockd.zip / sockd.HLP (.txt) < prev    next >
OS/2 Help File  |  1997-05-18  |  61KB  |  1,713 lines
  1.  
  2. ΓòÉΓòÉΓòÉ 1. SockD description ΓòÉΓòÉΓòÉ
  3.  
  4.  The multi-threaded socks server for OS/2 enables to build a firewall gateway 
  5. on an OS/2 (Warp) system. The objective is just to interconnect small TCP/IP PC 
  6. Lan with the public network (through a "Service Provider"). 
  7.  
  8.  Like in all "standard" sockd server, the protection is build in a 
  9. configuration file (sockd.cfg in the ETC directory). 
  10.  
  11.  Access is controlled with two statements "deny" or "permit". Origin address 
  12. and subnet mask and destination address and mask can be checked for a 
  13. destination port number... 
  14.  
  15. For applications using socks version 4 protocol the support  is only for TCP 
  16. application due to the protocol stack. 
  17.  
  18.  The current version has support for three LAN adapters (LAN0, LAN1 and LAN2), 
  19. and two SLIP or PPP adapters (sl0, sl1, ppp0 and ppp1). One of the "serial" 
  20. adapters can be configured in "auto-dial" to give access to the Internet 
  21. through a "network" provider. 
  22.  
  23.  The current version supports SOCKS Version 4 and 5. In SOCKS version 5, only 
  24. NO AUTHENTICATION REQUIRED and USERNAME/PASSWORD authentication methods are 
  25. supported. The GSSAPI support is NOT implemented. 
  26.  
  27.  In V5 only support for IP V4 addresses is provided not V6.  DNS names are 
  28. evidendly supported. 
  29.  
  30.  To be used, a correct support of the TCP/IP names must be implemented in  the 
  31. way the "client" stations can convert external names in IP addresses.  This 
  32. restriction can be modified with SOCKS Version 5 where DNS names have  to be 
  33. resolved only on the SOCKD station. 
  34.  
  35.  To provide the correct "names" support in Socks V4, we use the DNS kit of 
  36. TCP/IP V2.0  on the same workstation as "sockD". In this way this "nameD" 
  37. server can provide  caching mechanism to the external (and internal) name 
  38. servers.  We used also the DDNS kit of Warp Server in a similar configuration. 
  39.  
  40.  In Socks V5, only a resolv file pointing to a "public" name server and an 
  41. "hosts" file to traduce "internal" names are required. The usage of a real 
  42. "caching" name server is NOT mandatory. The customization of the "SockD" server 
  43. is easier. 
  44.  
  45. The support of UDP associated of V5 is a little bit modified to add support for 
  46. a "remote" ping command when the destination port is "1". In this case sockd 
  47. opens a "raw" socket with protocol "icmp" to ping the external host and 
  48. communicates with the standard UDP Associated protocol to the "client" host. 
  49.  
  50.  
  51. ΓòÉΓòÉΓòÉ 2. Auto-dial facility. ΓòÉΓòÉΓòÉ
  52.  
  53. You need to customize first the access to your network provider. 
  54.  
  55. SockD was only tested with IBM Global Network. When the access is working with 
  56. the "dialer.exe", you have to customize two "cmd" files one to get the access 
  57. and the second one to close it. 
  58.  
  59. This facility is only supported on one adapter sl0, sl1, ppp0 or ppp1. It was 
  60. only tested on sl0. 
  61.  
  62. To check if the connection is OK, sockd uses the "flags" of the adapter status. 
  63. When the sl0 adapter is "<UP,POINTTOPOINT>", the flags are "811" or 
  64. "<UP,POINTTOPOINT,RUNNING>" ("851")... 
  65.  
  66. Sockd reads normally a sockd.cfg and sockd.rte files in the ETC directory. 
  67. These files are the socks configuration. In auto-dial mode, sockd tries to 
  68. build an "automatic" config. It should be OK for the first tests. If you want 
  69. to look at this default config, you have just to read the sockd.log file (in 
  70. the sockd directory) after stopping sockd. 
  71.  
  72. By sample I used this sockdial.cmd whith a correct userid/password and account 
  73. to start the connection. 
  74.  
  75. /************************************************/
  76. /*                                              */
  77. /* sockdial.cmd :  to start the slip connection */
  78. /*                                              */
  79. /************************************************/
  80. 'start dialer account userid password -d'
  81.  
  82. And this sockclos.cmd to stop the connection after the "delay" without session 
  83. is expired. 
  84.  
  85. /***********************************************/
  86. /*                                             */
  87. /* sockclos.cmd :  to stop the slip connection */
  88. /*                                             */
  89. /***********************************************/
  90. 'dialer -c'
  91.  
  92. These two cmd MUST be put in a subdirectory in the PATH statement (I used 
  93. \TCPIP\BIN). 
  94.  
  95. Evidendly you have to enable the "auto-dial" function through the "dial-up" 
  96. option of the "config" menu (and setup your command names and the "delay" 
  97. time). Then you have to stop/start sockd. 
  98.  
  99. An other method consists in starting directly sockd with a parameter: 
  100.  
  101.   start sockd -dsl0
  102.  
  103.   where:  sl0  is the auto-dial adapter
  104.  
  105. In this case you have to keep the default for other parameters: "sockdial.cmd", 
  106. "sockclos.cmd" and 5 minutes of delay. 
  107.  
  108. The delay time should be shorter than the "delay" set in the "dialer" 
  109. configuration to keep the control of the connection in "sockd". 
  110.  
  111.  
  112. ΓòÉΓòÉΓòÉ 3. sockd.cfg ΓòÉΓòÉΓòÉ
  113.  
  114.  The configuration files are saved in the ETC directory. 
  115.  
  116. deny   0.0.0.0 0.0.0.0 9.0.0.0 255.0.0.0 gt 0
  117. permit 9.0.0.0 255.0.0.0 0.0.0.0 0.0.0.0 ge 1024
  118. permit 9.0.0.0 255.0.0.0 0.0.0.0 0.0.0.0 eq 21
  119. permit 9.0.0.0 255.0.0.0 0.0.0.0 0.0.0.0 eq 20
  120. permit *=PhilG,Test 9.0.0.0 255.0.0.0 0.0.0.0 0.0.0.0 eq 23
  121. permit 9.0.0.0 255.0.0.0 0.0.0.0 0.0.0.0 eq 70
  122. permit 9.0.0.0 255.0.0.0 0.0.0.0 0.0.0.0 eq 80
  123.  
  124.  A list of userids can be used in addition of IP addresses on the "permit" 
  125. statement. They are case sensitive. The value sent from the OS/2 Warp station 
  126. comes from the USER variable set in the "config.sys" in SOCKS V4. 
  127.  
  128.  On the time being no checking of "password" is performed (through identd). 
  129.  
  130. In SOCKS V5, the userid used in userid/password authentication is checked with 
  131. the userid list in the permit statement if *= field is set. 
  132.  
  133.  Good practice specifies a first statement to denies all external accesses to 
  134. your "private" network (all ports) with: 
  135.  
  136.  "deny 0.0.0.0 0.0.0.0 nnn.nnn.nnn.nnn mmm.mmm.mmm.mmm gt 0"  where nnn is your 
  137. network number and mmm the mask. 
  138.  
  139.  then you can permit all stations from your network to access all TCP 
  140. applications through the socks gateway with: 
  141.  
  142. "permit nnn.nnn.nnn.nnn mmm.mmm.mmm.mmm 0.0.0.0 0.0.0.0 gt 0" 
  143.  
  144. "proxy" statements can be added if you require to interconnect sockd servers. 
  145. The syntax is like : "proxy  IP_addr  port_nb  subnet_nb  subnet_mask 
  146. [site_certificate] " 
  147. Where : 
  148.  IP_addr is the IP address of next proxy server 
  149.  port_nb is the port number (1080 by default) of this proxy server 
  150.  subnet_nb is the destination subnet number we can access through this proxyu 
  151.  subnet_mask the destination subnet mask 
  152.  site_certificate the file to use for authentication and encryption 
  153.  
  154.  
  155. ΓòÉΓòÉΓòÉ 4. sockd.pro ΓòÉΓòÉΓòÉ
  156.  
  157.  
  158.  SOCKD uses also a profile file (sockd.pro) in the ETC directory to save the 
  159. number of sessions set, server port nb, the window position, the level of 
  160. logging used ("Full", "all Sessions", "only errors and sessions refused 
  161. (Minimum)" or "No logging") and the font used on main window. 
  162.  
  163.  In the second line of this file, we have the "auto dial" parameters:  is this 
  164. facility enabled (Y or N), the dial command, the hangup command,  and the 
  165. "short hold mode" delay. 
  166.  
  167.  In addition a "TCP" time-out and a "UDP" time-out (in seconds) are  also set. 
  168. These permit to "tune" the delay sockd is waiting for the next  transaction 
  169. before considering the session is lost.  If these parameters are too short 
  170. sockd is cutting the session during a  normal "wait" time. If they are too 
  171. long, some "client" threads can be  blocked and are not available for "new" 
  172. sessions. 
  173.  
  174.  The defaults are respectively 20 minutes for TCP and 50 seconds for UDP 
  175. applications. TCP is really using a "session". In UDP there is no real 
  176. session. The communication is never really closed. The UDP time-out is used  to 
  177. standardly close this communication. SockD was tested with Real-Audio  UDP 
  178. application and archie as UDP associate applications. The default of  50 
  179. seconds was enough to use both applications with a dial-up connection.  The 
  180. default of 20 minutes for TCP applications was set bigger than the  standard 
  181. FTP time-out (15 minutes). It is NOT enough for "permanent"  telnet sessions. 
  182.  
  183. A third line contains info on log archiving : yes or no, delay in hours or 
  184. days, delay value, maximum number of files to archive. The fifth parm in this 
  185. line permits to support only socks V5 userid/password authentication if a 
  186. userid is set on a permit statement. In Socks V4 there is no password checking. 
  187. Normally sockd is giving the same process to V4 as V5. Enabling this option 
  188. obliges to use a password in addition to the userid. 
  189.  
  190.  This file is created automatically by sockd.exe 
  191.  
  192.  
  193. ΓòÉΓòÉΓòÉ 5. sockd.rte ΓòÉΓòÉΓòÉ
  194.  
  195.  
  196.  Another configuration file (sockd.rte) is required for SOCKS_BIND in the ETC 
  197. directory describing the gateway adapters and IP addresses. Most of the 
  198. applications (Web Explorer, Rtelnet, ...) use only SOCKS_CONNECT. That's the 
  199. reason why I put "sockd.rte" as optional.... But if you want to use Rftp you 
  200. need the SOCKS_BIND support and then sockd.rte. 
  201.  
  202.  It is a list of the local adapter addresses and the neworks you can reach 
  203. through these... These definitions are used in sequence for testing an address. 
  204. Thus it seems better to put the more restrictive definitions first (describing 
  205. private network access) and the "public network" adapter finally (giving access 
  206. to world). 
  207.  
  208.  By sample : 
  209.  
  210. 9.36.69.41    9.36.69.32 255.255.255.224
  211. 9.132.89.238  0.0.0.0    0.0.0.0
  212.  
  213. If you plan to use the auto-dial facility avoid to set routing for the dial-up 
  214. adapter. If no route file is found, sockd builds one with your LAN adapters 
  215. giving access to their local subnets and put a last dynamic entry for the 
  216. switched adapter giving access to world (0.0.0.0). 
  217.  
  218. You can want to have other subnets accessible through fixed (LAN) adapters. For 
  219. that you must define a sockd.rte with a line per subnet and setting in first 
  220. parameter the local IP address giving access to it. Sockd 'll add dynamically a 
  221. last entry for the switched adapter giving access to 0.0.0.0 
  222.  
  223.  By sample : 
  224.  
  225. 9.36.71.9     9.36.71.0   255.255.255.0
  226. 9.132.89.238  9.0.0.0     255.0.0.0
  227. 9.132.89.238  198.74.69.0 255.255.255.0
  228.  
  229.  
  230. ΓòÉΓòÉΓòÉ 6. sockd.usr ΓòÉΓòÉΓòÉ
  231.  
  232.  
  233. This file is in the ETC directory  for Socks version 5 userid/password 
  234. authentication. On the time being, no encryption technic is used on this 
  235. confidential dataset. A userid as a password can theoretically use 256 
  236. characters. I think in our test implementation it is limited to 255 (due to the 
  237. end of string character). 
  238.  
  239.  By sample : 
  240.  
  241. userid01 password01
  242. userid02 password02
  243.  
  244.  
  245. ΓòÉΓòÉΓòÉ 7. Utilisation: ΓòÉΓòÉΓòÉ
  246.  
  247.  
  248.  Start sockd without any parameter or with some of these options: 
  249.  
  250.      "-c" option: The number of concurrent clients is 32 by default. It can be 
  251.       changed at startup with the -c parameter or by modifying the sockd.pro 
  252.       profile file with the menu option. By sample :"sockd -c64" to support 64 
  253.       simultaneous clients. Note there is NO space between -c and the value. 
  254.       This number should be between 8 and 255. Each client uses one thread (in 
  255.       addition to the base sockd thread). 
  256.  
  257.      "-l" option: to suppress logging (sockd.log file in the current 
  258.       directory) 
  259.  
  260.      "-i" option: to start iconized . 
  261.  
  262.      "-d" option: to setup an auto-dial adapter, by sample "-dsl0". 
  263.  
  264.      "-p" option: by default sockd uses the port 1080. You can change it 
  265.       starting "sockd -p2080" by sample. 
  266.  
  267.   If you want to use more than one option, specify different parameters: "start 
  268.  sockd -c48 -p2080 -i". 
  269.  
  270.   The frame forwarding MUST be disabled (with the "ipgate off" command or 
  271.  through MPTS customization) to protect the access to your "internal" network. 
  272.  
  273.   The "socks" support is required to run (and use) applications through 
  274.  gateway. (see SOCKS FORUM) or a Web Browser with "socks" support (like Web 
  275.  Explorer for  OS/2). 
  276.  
  277.  
  278. ΓòÉΓòÉΓòÉ 8. SOCKD menu ΓòÉΓòÉΓòÉ
  279.  
  280.      "Config": create, modify or simply check your configuration 
  281.  
  282.         -  "edit": to create or modify "line by line" the sockd.cfg in ETC 
  283.            directory 
  284.  
  285.         -  "proxy": to define proxy servers and the subnets they are giving 
  286.            access. 
  287.  
  288.         -  "view": to review the configuration in memory and eventualy change 
  289.            it    with the standard MLE (Multiple Line Entry field) keyboard 
  290.            manipulation.    (select text with mouse button 1 or Shift key and 
  291.            move the cursor,    then cut, copy and paste text with Ctrl+Delete, 
  292.            Shift+Delete and Shift+Insert) 
  293.  
  294.         -  "profile": to change the maximum number of concurrent sessions, 
  295.            the server port number or the logging level. 
  296.  
  297.         -  "route": to configure the sockd.rte file in ETC directory. 
  298.  
  299.         -  "save conf": to save the sockd.cfg from memory to ETC directory 
  300.  
  301.         -  "userid": for Socks V5 Userid/Password authentication method 
  302.  
  303.         -  "dial-up": to customize auto-dial facility 
  304.  
  305.         -  "font": to select the font used in the main window. 
  306.  
  307.      "reset": If you want to activate a change, a new profile or config 
  308.  
  309.         -  "server": to stop/restart the server 
  310.  
  311.         -  "log file": to clean the log file when reports are too long. 
  312.  
  313.      "Report": 
  314.  
  315.         -  "accepted": to check all sessions through this server 
  316.  
  317.         -  "denied": to check all demands rejected by the server. 
  318.  
  319.         -  "connect": to read the dial-up connection time in auto-dial mode. 
  320.  
  321.      "Help": to read this help file. 
  322.  
  323.      "Exit": to save the "profile" file and exit. 
  324.  
  325.  
  326. ΓòÉΓòÉΓòÉ 9. DNS support ΓòÉΓòÉΓòÉ
  327.  
  328.  
  329. ΓòÉΓòÉΓòÉ 9.1. How to setup a Name server ΓòÉΓòÉΓòÉ
  330.  
  331.  
  332.  To solve the V4 "name" problem, I put the DNS kit (at CSD UN60004 level) on 
  333. the PS/VP. This name server should be customized with caching to the external 
  334. name server(s) and to internal domain name server. On the "client" station the 
  335. resolv2 file points to the socks gateway address as the name server (the DNS 
  336. running on the sockd station can be the only name server on this small subnet). 
  337.  
  338.  Here after the configuration files used during our tests, where: 
  339.  
  340.      Where test.benelux.ibm.com (9.36.71.0) is the 'private' domain 
  341.  
  342.      ztmaixn1.benelux.ibm.com (9.132.56.2) is the external name server for the 
  343.       ibm.com domain and ns01.ny.us.ibm.net (165.87.194.244) is the external 
  344.       DNS server. 
  345.  
  346.      The socks gateway is using 9.132.89.238 on the "ibm.com" adapter and 
  347.       9.36.71.9 on the "secure" side (philg.benelux.ibm.com). 
  348.  
  349.      Tests were performed from testuser.test.benelux.ibm.com (9.36.71.10). 
  350.  
  351.      All "external" sessions were performed through the sl0 adapter and a 
  352.       connection to IBM Global Network as "Service" provider. 
  353.  
  354.  In fact, on a small LAN with just a few PCs connected a "hosts" file must be 
  355.  enough to succeed with DNS conversion in Socks V5. 
  356.  
  357.   hosts file in ETC directory
  358.  
  359.   9.132.89.238      bedb238.benelux.ibm.com
  360.   9.36.71.9         bedb238.philg.benelux.ibm.com
  361.   9.36.71.10        testuser.philg.benelux.ibm.com
  362.   165.87.194.244    ns01.ny.us.ibm.net
  363.   128.123.35.151    hobbes.nmsu.edu
  364.   206.101.97.101    www.lycos.com
  365.   205.216.146.70    www.yahoo.com
  366.  
  367.  In Socks V4, you can perform the first sockd tests just with a similar hosts 
  368.  file. But quickly, you should be blocked and due to the protocol you need to 
  369.  start a "named" server on your sockd gateway. You need then a "resolv2" file 
  370.  on your LAN attached PC pointing to your named server. 
  371.  
  372.  In any case keep also an "hosts" file on your sockd PC, because the code uses 
  373.  a "gethostbyaddr()" macro to get the "hostname" of the workstation. Sometimes 
  374.  the named server doesn't answer and you have to start sockd before named. You 
  375.  need then the "hosts" file to get a name. 
  376.  
  377.  
  378. ΓòÉΓòÉΓòÉ 9.2. DNS Kit of TCP/IP V2 ΓòÉΓòÉΓòÉ
  379.  
  380.  named.bt 
  381.  
  382. ;
  383. ; NAMED.BT file for name server configuration.
  384. ;
  385. ; type       domain                      source file or host
  386. ;
  387. domain   philg.benelux.ibm.com
  388. cache    .                          d:\\tcpip\\etc\\namedb\\named.ca
  389. primary  philg.benelux.ibm.com      d:\\tcpip\\etc\\namedb\\named.dom
  390. primary  71.36.9.in-addr.arpa       d:\\tcpip\\etc\\namedb\\named.rev
  391. ;
  392. ;
  393. domain   benelux.ibm.com
  394. primary  ztmaixn1.benelux.ibm.com  9.132.56.2
  395. primary  9.in-addr.arpa            9.132.56.2
  396. ;
  397. domain   ibm.net
  398. primary  ns01.ny.us.ibm.net        165.87.194.244
  399. primary  .in-addr.arpa             165.87.194.244
  400. ;
  401.  
  402.  named.ca 
  403.  
  404. ;
  405. ; define parent(root) domain nameserver (Note trailing dot)
  406. ;
  407. philg.benelux.ibm.com.        99999999  IN  NS  bedb238.benelux.ibm.com.
  408. 71.36.9.in-addr.arpa.         99999999  IN  NS  bedb238.benelux.ibm.com.
  409. benelux.ibm.com.              99999999  IN  NS  ztmaixn1.benelux.ibm.com.
  410. ibm.com.                      99999999  IN  NS  ztmaixn1.benelux.ibm.com.
  411. 9.                            99999999  IN  NS  ztmaixn1.benelux.ibm.com.
  412. 9.in-addr.arpa.               99999999  IN  NS  ztmaixn1.benelux.ibm.com.
  413. in-addr.arpa.                 99999999  IN  NS  ns01.ny.us.net.com.
  414. ;
  415. ; address of domain nameservers
  416. ;
  417. bedb238.philg.benelux.ibm.com.  99999999  IN  A   9.36.71.9
  418. bedb238.benelux.ibm.com.        99999999  IN  A   9.132.89.238
  419. ztmaixn1.benelux.ibm.com.       99999999  IN  A   9.132.56.2
  420. beda002.benelux.ibm.com.        99999999  IN  A   9.132.88.2
  421. ns01.ny.us.net.com.             99999999  IN  A   165.87.194.244
  422. ;
  423.  
  424. Where ns01.ny.us.net.com is the name server of the Internet provider... 
  425.  
  426.  named.dom 
  427.  
  428. ;
  429. ;********************************
  430. ;*  Start of Authority Records  *
  431. ;********************************
  432. ;
  433. @ IN SOA  bedb238.philg.benelux.ibm.com.  bedb238.philg.benelux.ibm.com. (
  434.         93052601 ; Serial number for this data (yymmdd##)
  435.         86400    ; Refresh value for secondary name servers
  436.         300      ; Retry value for secondary name servers
  437.         864000   ; Expire value for secondary name servers
  438.         3600 )   ; Minimum TTL value
  439. ;
  440. @      IN  NS   bedb238.philg.benelux.ibm.com.
  441. ibm.com.   IN  NS   bedb238.philg.benelux.ibm.com.
  442. ibm.com.   IN  NS   ztmaixn1.benelux.ibm.com.
  443. com.   IN  NS   bedb238.philg.benelux.ibm.com.
  444. com.   IN  NS   ns01.ny.us.ibm.net
  445. edu.   IN  NS   ns01.ny.us.ibm.net
  446. be.    IN  NS   ns01.ny.us.ibm.net
  447. ;
  448. ;********************************
  449. ;*  Domain Address Information  *
  450. ;********************************
  451. ;
  452. bedb238                    86400  IN  A      9.36.71.9
  453.                                   IN  HINFO  IBM-PS/2 OS/2 3.0
  454. ;
  455. testuser                   86400  IN  A      9.36.71.10
  456.                                   IN  HINFO  IBM-PS/2 OS/2 3.0
  457. ;
  458. bedb238.benelux.ibm.com.   86400  IN  A      9.132.89.238
  459. bedb237.benelux.ibm.com.   86400  IN  A      9.132.89.237
  460. ns01.ny.us.ibm.net         86400  IN  A      165.87.194.244
  461. ztmaixn1.benelux.ibm.com   86400  IN  A      9.132.56.2
  462. w3.almaden.ibm.com.        86400  IN  A      129.33.24.62
  463. w3.pe.au.ibm.com.          86400  IN  A      9.8.32.2
  464. w3.austin.ibm.com.         86400  IN  A      9.3.246.8
  465. w3.bocaraton.ibm.com.      86400  IN  A      9.83.4.179
  466. w3.portsmouth.uk.ibm.com.  86400  IN  A      9.180.145.185
  467. w3.hursley.ibm.com.        86400  IN  A      9.20.2.34
  468. w3.issc.ibm.com.           86400  IN  A      9.242.89.217
  469. isscw3.raleigh.ibm.com.    86400  IN  A      9.67.1.114
  470. w3nhd.raleigh.ibm.com.     86400  IN  A      9.67.195.102
  471. netstd.raleigh.ibm.com.    86400  IN  A      9.67.1.114
  472. w3.raleigh.ibm.com.        86400  IN  A      9.67.4.22
  473. www.tcp.raleigh.ibm.com.   86400  IN  A      9.67.106.6
  474. www.lycos.com.             86400  IN  A      206.101.97.101
  475. www.yahoo.com.             86400  IN  A      205.216.146.70
  476.  
  477. The translation of www.lycos.com, www.yahoo.com, ... Are there to have a method 
  478. to start a dial-up connection without the external DNS server. These name 
  479. translations are required for Socks V4 auto-dial process... 
  480.  
  481. You must setup there the addresses of the WWW servers set in the quicklist of 
  482. the end-users connected on the local LAN while Web explorer is not supporting 
  483. V5. 
  484.  
  485.  named.rev 
  486.  
  487. ;
  488. ;********************************
  489. ;*  Start of Authority Records  *
  490. ;********************************
  491. ;
  492. 71.36.9.in-addr.arpa. IN  SOA   bedb238.philg.benelux.ibm.com. (
  493.         93052601 ; Serial number for this data (yymmdd##)
  494.         86400    ; Refresh value for secondary name servers
  495.         300      ; Retry value for secondary name servers
  496.         864000   ; Expire value for secondary name servers
  497.         3600 )   ; Minimum TTL value
  498.  
  499. 71.36.9.in-addr.arpa.  IN  NS   bedb238.philg.benelux.ibm.com.
  500. ;
  501. 9              IN  PTR   bedb238.philg.benelux.ibm.com.
  502. 10             IN  PTR   testuser.philg.benelux.ibm.com.
  503. 237.89.132.9.in-addr.arpa.  IN  PTR   bedb237.benelux.ibm.com.
  504. 238.89.132.9.in-addr.arpa.  IN  PTR   bedb238.benelux.ibm.com.
  505. 101.97.101.206.in-addr.arpa.  IN  PTR  www.lycos.com.
  506. 70.146.216.205.in-addr.arpa.  IN  PTR  www.yahoo.com.
  507.  
  508. The translation of bedb238.benelux.ibm.com is required to start sockd when the 
  509. name server is running, because 9.132.89.238 is the IP address of the "lan0" 
  510. adapter. 
  511. SockD uses a "gethostbyaddr()" macro to get the host-name of the system where 
  512. it is running. If the name server can not give it, sockd is blocked during 
  513. start-up... 
  514.  
  515.  
  516. ΓòÉΓòÉΓòÉ 9.3. DDNS Kit of Warp server ΓòÉΓòÉΓòÉ
  517.  
  518. In the \MPTN\ETC\NAMEDB directory we used the following config files. 
  519.  
  520.  named.bt 
  521.  
  522. ;
  523. ; NAMED.BT file for name server configuration.
  524. ;
  525. ; type       domain                  source file or host
  526. ;
  527. domain   philg.benelux.ibm.com
  528. primary  philg.benelux.ibm.com c:\\mptn\\etc\\namedb\\named.dom presecured nokeytosec
  529. primary  71.36.9.in-addr.arpa  c:\\mptn\\etc\\namedb\\named.rev presecured nokeytosec
  530. ;
  531. ;
  532. cache    .              c:\\mptn\\etc\\namedb\\named.ca  presecured nokeytosec
  533. ;
  534.  
  535.  named.dom 
  536.  
  537. ;
  538. ;********************************
  539. ;*  Start of Authority Records  *
  540. ;********************************
  541. ;
  542. @   IN  SOA        bedb238.philg.benelux.ibm.com. (
  543.         96090101 ; Serial number for this data (yymmdd##)
  544.         86400    ; Refresh value for secondary name servers
  545.         300      ; Retry value for secondary name servers
  546.         864000   ; Expire value for secondary name servers
  547.         3600 )   ; Minimum TTL value
  548. ;
  549. @      IN  NS   bedb238.philg.benelux.ibm.com.
  550. ;
  551. ;********************************
  552. ;*  Domain Address Information  *
  553. ;********************************
  554. ;
  555. bedb238                    86400  IN  A      9.36.71.9
  556.                                   IN  HINFO  IBM-PS/2 OS/2 3.0
  557. ;
  558. testuser                   86400  IN  A      9.36.71.10
  559.                                   IN  HINFO  IBM-PS/2 OS/2 3.0
  560. ;
  561. ns01.ny.us.ibm.net         86400  IN  A      165.87.194.244
  562. www.lycos.com.             86400  IN  A      206.101.97.101
  563. www.yahoo.com.             86400  IN  A      205.216.146.70
  564.  
  565.  named.rev 
  566.  
  567. ;
  568. ;********************************
  569. ;*  Start of Authority Records  *
  570. ;********************************
  571. ;
  572. 71.36.9.in-addr.arpa. IN  SOA  bedb238.philg.benelux.ibm.com. (
  573.         93052601 ; Serial number for this data (yymmdd##)
  574.         86400    ; Refresh value for secondary name servers
  575.         300      ; Retry value for secondary name servers
  576.         864000   ; Expire value for secondary name servers
  577.         3600 )   ; Minimum TTL value
  578.  
  579. 71.36.9.in-addr.arpa.  IN  NS   bedb238.philg.benelux.ibm.com.
  580. ;
  581. 9.71.36.9.in-addr.arpa.       IN  PTR   bedb238.philg.benelux.ibm.com.
  582. 10.71.36.9.in-addr.arpa.      IN  PTR   testuser.philg.benelux.ibm.com.
  583. 101.97.101.206.in-addr.arpa.  IN  PTR   www.lycos.com.
  584. 70.146.216.205.in-addr.arpa.  IN  PTR   www.yahoo.com.
  585.  
  586.  named.ca 
  587.  
  588. ;
  589. ; define parent(root) domain nameserver (Note trailing dot)
  590. ;
  591. in-addr.arpa.           99999999  IN  NS  ns01.ny.us.net.com.
  592. ;
  593. ; address of domain nameservers
  594. ;
  595. ns01.ny.us.net.com.     99999999  IN  A   165.87.194.244
  596. ;
  597.  
  598.  
  599. ΓòÉΓòÉΓòÉ 9.4. resolv2 on SockD server ΓòÉΓòÉΓòÉ
  600.  
  601. domain philg.benelux.ibm.com
  602. nameserver 9.36.71.9
  603.  
  604.  
  605. ΓòÉΓòÉΓòÉ 9.5. resolv on SockD server ΓòÉΓòÉΓòÉ
  606.  
  607. domain philg.benelux.ibm.com
  608. nameserver 9.36.71.9
  609.  
  610.  
  611. ΓòÉΓòÉΓòÉ 9.6. resolv2 on end-user workstation ΓòÉΓòÉΓòÉ
  612.  
  613. domain philg.benelux.ibm.com
  614. nameserver 9.36.71.9
  615.  
  616.  
  617. ΓòÉΓòÉΓòÉ 9.7. Test configuration ΓòÉΓòÉΓòÉ
  618.  
  619.                  ----
  620.             ----     ---
  621.         ----            ----
  622.     ----    Internet        --
  623.        ----                    -
  624.            ------ IBM IGN   --
  625.                 ---*-------
  626.                    *
  627.                    *
  628.                 *******                     testuser
  629.                  *   *  Modem              ----------
  630.                   * *   Dial-up            *Thinkpad*
  631.                    *                       ----*-----
  632.       * *          *                           *
  633.     *     *  ------*------    Ethernet         *9.36.71.10
  634.    * T-R   *** PS/VP     *---------------------*---
  635.     *     *  * bebd238   *9.36.71.9
  636.       * *    -------------
  637.          9.132.89.238
  638.  ibm.com                          philg.benelux.ibm.com
  639.  9.0.0.0                             9.36.71.0
  640.  
  641. With a correct setup, it is possible to use Internal servers (ibm.com) without 
  642. dialing from "testuser". If an external server is used (by sample 
  643. www.yahoo.com) the auto-dial is automaticcally used. 
  644.  
  645. The choice is done through "sockd.rte" configuration. By default sockd gives 
  646. only access to the "local" subnet on the LAN adapter (9.132.88.0). 
  647.  
  648.  
  649. ΓòÉΓòÉΓòÉ 10. Proxy  support ΓòÉΓòÉΓòÉ
  650.  
  651.  A "proxy" socks server is implemented. To use it you need to know the IP 
  652. address of the next sockd for OS/2 server and the subnets you can access 
  653. through this remote sockd. 
  654.  
  655.  From a LAN connected to Internet in "auto-dial" mode it is possible to access 
  656. servers located on an other LAN attached to Internet through a sockd using a 
  657. fixed IP address (mainly with a leased line). 
  658.  
  659.  You must "permit" the access on both sockd servers. Only the dial-up sockd has 
  660. to define the "leased line attached" sockd with a "proxy" statement. 
  661.  
  662.  
  663. ΓòÉΓòÉΓòÉ 11. Archiving sockd log files and reporting ΓòÉΓòÉΓòÉ
  664.  
  665.  Sockd can now archive its log files. The setup is done through the "profile" 
  666. option of the main window menu. Four parameters are saved in the third line of 
  667. the sockd.pro file in the ETC directory. The first parameter indicates if Yes 
  668. or No the option is selected. The second parameter is "H" for hours or "D" for 
  669. days. The third gives the delay used to close the sockd.log file and rename it 
  670. to "sockdlog.XXX" where XXX is a three digits number. The fourth indicates the 
  671. maximum number of archived files (+ the current sockd.log). 
  672.  
  673.  The default is to keep seven files and to archive every 24 hours. With this 
  674. setup you can build a weekly report using the sample REXX reporting program 
  675. "sockdrep.cmd" (just type "sockdrep" without parm in the directory sockd is 
  676. running)... 
  677.  
  678.  
  679. ΓòÉΓòÉΓòÉ 12. SOCKS version 4 : A protocol for TCP proxy across firewalls ΓòÉΓòÉΓòÉ
  680.  
  681.  
  682.  A protocol for TCP proxy across firewalls 
  683.  
  684. SOCKS was originally developed by David Koblas and subsequently modified and 
  685. extended by Ying-Da Lee from NEC Systems Laboratory to its current running 
  686. version -- version 4. 
  687.  
  688. It is a protocol that relays TCP sessions at a firewall host to allow 
  689. application users transparent access across the firewall. Because the protocol 
  690. is independent of application protocols, it can be (and has been) used for many 
  691. different services, such as telnet, ftp, finger, whois, gopher, WWW,... 
  692.  
  693.  Access control can be applied at the beginning of each TCP session; thereafter 
  694. the server simply relays the data between the client and the application 
  695. server, incurring minimum processing overhead. Since SOCKS never has to know 
  696. anything about the application protocol, it should also be easy for it to 
  697. accommodate applications which use encryption to protect their traffic from 
  698. nosey snoopers. 
  699.  
  700.  Two operations are defined: CONNECT and BIND. 
  701.  
  702.  
  703. ΓòÉΓòÉΓòÉ 12.1. CONNECT ΓòÉΓòÉΓòÉ
  704.  
  705.  
  706.  The client connects to the SOCKS server and sends a CONNECT request when it 
  707. wants to establish a connection to an application server. The client includes 
  708. in the request packet the IP address and the port number of the destination 
  709. host, and userid, in the following format. 
  710.  
  711.        +----+----+----+----+----+----+----+----+----+----+....+----+
  712.        | VN | CD | DSTPORT |      DSTIP        | USERID       |NULL|
  713.        +----+----+----+----+----+----+----+----+----+----+....+----+
  714. # bytes: 1    1      2              4           variable       1
  715.  
  716.  
  717.  VN is the SOCKS protocol version number and should be 4. CD is the SOCKS 
  718. command code and should be 1 for CONNECT request. NULL is a byte of all zero 
  719. bits. 
  720.  
  721.  The SOCKS server checks to see whether such a request should be granted based 
  722. on any combination of source IP address, destination IP address, destination 
  723. port number, the userid, and information it may obtain by consulting IDENT, cf. 
  724. RFC 1413.  If the request is granted, the SOCKS server makes a connection to 
  725. the specified port of the destination host. A reply packet is sent to the 
  726. client when this connection is established, or when the request is rejected or 
  727. the operation fails. 
  728.  
  729.  
  730.        +----+----+----+----+----+----+----+----+
  731.        | VN | CD | DSTPORT |      DSTIP        |
  732.        +----+----+----+----+----+----+----+----+
  733. # bytes: 1    1      2              4
  734.  
  735.  
  736.  VN is the version of the reply code and should be 0. CD is the result code 
  737. with one of the following values: 
  738.  
  739.  
  740.   90: request granted
  741.   91: request rejected or failed
  742.   92: request rejected becasue SOCKS server cannot connect to
  743.       identd on the client
  744.   93: request rejected because the client program and identd
  745.       report different user-ids
  746.  
  747.  
  748.  The remaining fields are ignored. 
  749.  
  750.  The SOCKS server closes its connection immediately after notifying the client 
  751. of a failed or rejected request. For a successful request, the SOCKS server 
  752. gets ready to relay traffic on both directions. This enables the client to do 
  753. I/O on its connection as if it were directly connected to the application 
  754. server. 
  755.  
  756.  
  757. ΓòÉΓòÉΓòÉ 12.2. BIND ΓòÉΓòÉΓòÉ
  758.  
  759.  
  760.  The client connects to the SOCKS server and sends a BIND request when it wants 
  761. to prepare for an inbound connection from an application server. This should 
  762. only happen after a primary connection to the application server has been 
  763. established with a CONNECT.  Typically, this is part of the sequence of 
  764. actions: 
  765.  
  766.    1. bind(): obtain a socket 
  767.  
  768.    2. getsockname(): get the IP address and port number of the socket 
  769.  
  770.    3. listen(): ready to accept call from the application server 
  771.  
  772.    4. use the primary connection to inform the application server of  the IP 
  773.       address and the port number that it should connect to. 
  774.  
  775.    5. accept(): accept a connection from the application server 
  776.  
  777.   The purpose of SOCKS BIND operation is to support such a sequence but using a 
  778.  socket on the SOCKS server rather than on the client. 
  779.  
  780.   The client includes in the request packet the IP address of the application 
  781.  server, the destination port used in the primary connection, and the userid. 
  782.  
  783.          +----+----+----+----+----+----+----+----+----+----+....+----+
  784.          | VN | CD | DSTPORT |      DSTIP        | USERID       |NULL|
  785.          +----+----+----+----+----+----+----+----+----+----+....+----+
  786.   # bytes: 1    1      2              4           variable       1
  787.  
  788.   VN is again 4 for the SOCKS protocol version number. CD must be 2 to indicate 
  789.  BIND request. 
  790.  
  791.   The SOCKS server uses the client information to decide whether the request is 
  792.  to be granted. The reply it sends back to the client has the same format as 
  793.  the reply for CONNECT request, i.e., 
  794.  
  795.  
  796.         +----+----+----+----+----+----+----+----+
  797.         | VN | CD | DSTPORT |      DSTIP        |
  798.         +----+----+----+----+----+----+----+----+
  799.   #bytes: 1    1      2              4
  800.  
  801.   VN is the version of the reply code and should be 0. CD is the result code 
  802.  with one of the following values: 
  803.  
  804.  
  805.     90: request granted
  806.     91: request rejected or failed
  807.     92: request rejected becasue SOCKS server cannot connect to
  808.         identd on the client
  809.     93: request rejected because the client program and identd
  810.         report different user-ids.
  811.  
  812.  
  813.   However, for a granted request (CD is 90), the DSTPORT and DSTIP fields are 
  814.  meaningful.  In that case, the SOCKS server obtains a socket to wait for an 
  815.  incoming connection and sends the port number and the IP address of that 
  816.  socket to the client in DSTPORT and DSTIP, respectively. If the DSTIP in the 
  817.  reply is 0 (the value of constant INADDR_ANY), then the client should replace 
  818.  it by the IP address of the SOCKS server to which the cleint is connected. 
  819.  (This happens if the SOCKS server is not a multi-homed host.)  In the typical 
  820.  scenario, these two numbers are made available to the application client 
  821.  prgram via the result of the subsequent getsockname() call.  The application 
  822.  protocol must provide a way for these two pieces of information to be sent 
  823.  from the client to the application server so that it can initiate the 
  824.  connection, which connects it to the SOCKS server rather than directly to the 
  825.  application client as it normally would. 
  826.  
  827.   The SOCKS server sends a second reply packet to the client when the 
  828.  anticipated connection from the application server is established. The SOCKS 
  829.  server checks the IP address of the originating host against the value of 
  830.  DSTIP specified in the client's BIND request.  If a mismatch is found, the CD 
  831.  field in the second reply is set to 91 and the SOCKS server closes both 
  832.  connections.  If the two match, CD in the second reply is set to 90 and the 
  833.  SOCKS server gets ready to relay the traffic on its two connections. From then 
  834.  on the client does I/O on its connection to the SOCKS server as if it were 
  835.  directly connected to the application server. 
  836.  
  837.   For both CONNECT and BIND operations, the server sets a time limit (2 minutes 
  838.  in current CSTC implementation) for the establishment of its connection with 
  839.  the application server. If the connection is still not establiched when the 
  840.  time limit expires, the server closes its connection to the client and gives 
  841.  up. 
  842.  
  843.  
  844. ΓòÉΓòÉΓòÉ 13. SOCKS version 5 ΓòÉΓòÉΓòÉ
  845.  
  846.  
  847. ΓòÉΓòÉΓòÉ 13.1. RFC 1928 ΓòÉΓòÉΓòÉ
  848.  
  849. Network Working Group                                 M. Leech
  850. Request for Comments: 1928          Bell-Northern Research Ltd
  851. Category: Standards Track                             M. Ganis
  852.                                International Business Machines
  853.                                                         Y. Lee
  854.                                         NEC Systems Laboratory
  855.                                                       R. Kuris
  856.                                              Unify Corporation
  857.                                                      D. Koblas
  858.                                         Independent Consultant
  859.                                                       L. Jones
  860.                                        Hewlett-Packard Company
  861.                                                     March 1996
  862.  
  863.  
  864. ΓòÉΓòÉΓòÉ 13.2. Status of this Memo ΓòÉΓòÉΓòÉ
  865.  
  866.  
  867.  This document specifies an Internet standards track protocol for the  Internet 
  868. community, and requests discussion and suggestions for  improvements.  Please 
  869. refer to the current edition of the "Internet  Official Protocol Standards" 
  870. (STD 1) for the standardization state  and status of this protocol. 
  871. Distribution of this memo is unlimited. 
  872.  
  873.  Acknowledgments 
  874.  
  875.  This memo describes a protocol that is an evolution  of  the  previous 
  876. version  of  the protocol, version 4 [1]. This new  protocol stems from active 
  877. discussions and prototype  implementations  The  key contributors are: Marcus 
  878. Leech: Bell-Northern Research,  David  Koblas:  Independent  Consultant, 
  879. Ying-Da  Lee: NEC Systems Laboratory, LaMont Jones: Hewlett-Packard  Company, 
  880. Ron Kuris: Unify Corporation,  Matt  Ganis:  International Business Machines. 
  881.  
  882.  Introduction 
  883.  
  884.  The use of network firewalls, systems that effectively isolate an 
  885. organizations internal network structure from an exterior network,  such as the 
  886. INTERNET is becoming increasingly popular.  These  firewall systems typically 
  887. act as application-layer gateways between  networks, usually offering 
  888. controlled TELNET, FTP, and SMTP access.  With the emergence of more 
  889. sophisticated application layer protocols  designed to facilitate global 
  890. information discovery, there exists a  need to provide a general framework for 
  891. these protocols to  transparently and securely traverse a firewall. 
  892.  
  893.  There exists, also, a need for strong authentication of such  traversal in as 
  894. fine-grained a manner as is practical. This  requirement stems from the 
  895. realization that client-server  relationships emerge between the networks of 
  896. various organizations,  and that such relationships need to be controlled and 
  897. often strongly  authenticated. 
  898.  
  899.  The  protocol described here is designed to provide a frame-  work for 
  900. client-server applications in both the TCP and  UDP  domains  to  conveniently 
  901. and securely use the services of a  network firewall.  The protocol  is 
  902. conceptually  a  "shimlayer"  between the application layer and the transport 
  903. layer  and as such does not provide network-layer gateway  services  such as 
  904. forwarding of ICMP messages. 
  905.  
  906.  This  new  protocol extends the SOCKS Version 4 model to include  UDP, and 
  907. extends the framework to  include  provisions  for  generalized  strong 
  908. authentication schemes, and extends  the addressing scheme to encompass 
  909. domain-name and V6 IP addresses. 
  910.  
  911.  
  912. ΓòÉΓòÉΓòÉ 13.3. Procedure for TCP-based clients ΓòÉΓòÉΓòÉ
  913.  
  914.  
  915.  When a TCP-based client wishes to establish a connection  to  an object that 
  916. is reachable only via a firewall (such determination  is left up to the 
  917. implementation), it must  open  a  TCP  connection  to  the appropriate SOCKS 
  918. port on the SOCKS  server system.  The SOCKS service is conventionally  located 
  919. on  TCP  port 1080.  If the connection request succeeds, the  client enters a 
  920. negotiation for the authentication method to  be  used, authenticates with the 
  921. chosen method, then sends a  relay request.  The SOCKS server evaluates the 
  922. request,  and  either  establishes the appropriate connection or denies it. 
  923.  
  924.  The client connects to the server, and sends a version    identifier/method 
  925. selection message: 
  926.  
  927.   +----+----------+----------+
  928.   |VER | NMETHODS | METHODS  |
  929.   +----+----------+----------+
  930.   | 1  |    1     | 1 to 255 |
  931.   +----+----------+----------+
  932.  
  933.  The VER field is set to X'05' for this version of the protocol.-  The NMETHODS 
  934. field contains the number of method identifier  octets that appear in the 
  935. METHODS field. 
  936.  
  937.  The server selects from one of the methods given in METHODS,  and sends a 
  938. METHOD selection message: 
  939.  
  940.  
  941.    +----+--------+
  942.    |VER | METHOD |
  943.    +----+--------+
  944.    | 1  |   1    |
  945.    +----+--------+
  946.  
  947.  If the selected METHOD is X'FF', none of the methods  listed  by  the client 
  948. are acceptable, and the client MUST close the  connection. 
  949.  
  950.  The values currently defined for METHOD are: 
  951.  
  952.  
  953.   o  X'00' NO AUTHENTICATION REQUIRED
  954.   o  X'01' <A HREF=/draft-ietf-aft-gssapi-02.html>GSSAPI</A>
  955.   o  X'02' <A HREF=/draft-ietf-aft-username-password-01.html>USERNAME/PASSWORD</A>
  956.  
  957.   o  X'03' to X'7F' IANA ASSIGNED
  958.  
  959.   o  X'80' to X'FE' RESERVED FOR PRIVATE METHODS
  960.  
  961.   o  X'FF' NO ACCEPTABLE METHODS
  962.  
  963.  The client and server then enter a method-specific  subnegotiation 
  964. Descriptions  of the method-dependent subnegotiations  appear in separate 
  965. drafts. 
  966.  
  967.  Developers of new METHOD support for  this  protocol  should  contact IANA for 
  968. a METHOD number.  The ASSIGNED NUMBERS document  should be referred to for a 
  969. current  list  of  METHOD  numbers and their corresponding protocols. 
  970.  
  971.  Compliant  implementations  MUST  support  GSSAPI and SHOULD  support 
  972. USERNAME/PASSWORD authentication methods. 
  973.  
  974.  
  975.   The SOCKS request is formed as follows:
  976.  
  977.   +----+-----+-------+------+----------+----------+
  978.   |VER | CMD |  RSV  | ATYP | DST.ADDR | DST.PORT |
  979.   +----+-----+-------+------+----------+----------+
  980.   | 1  |  1  | X'00' |  1   | Variable |    2     |
  981.   +----+-----+-------+------+----------+----------+
  982.  Where:
  983.  
  984.   o  VER    protocol version: X'05'
  985.   o  CMD
  986.   o  CONNECT X'01'
  987.   o  BIND X'02'
  988.   o  UDP ASSOCIATE X'03'
  989.   o  RSV    RESERVED
  990.   o  ATYP   address type of following address
  991.      o  IP V4 address: X'01'
  992.      o  DOMAINNAME: X'03'
  993.      o  IP V6 address: X'04'
  994.   o  DST.ADDR       desired destination address
  995.   o  DST.PORT       desired destination port in network octet order
  996.  
  997.  The SOCKS server will typically evaluate the  request  based  on  source and 
  998. destination addresses, and return one or more  reply messages, as appropriate 
  999. for the request type. 
  1000.  
  1001.  
  1002. ΓòÉΓòÉΓòÉ 13.4. Addressing ΓòÉΓòÉΓòÉ
  1003.  
  1004.  
  1005.  In an address field (DST.ADDR,  BND.ADDR),  the  ATYP  field  specifies the 
  1006. type of address contained within the field: 
  1007.  
  1008.      X'01' 
  1009.  
  1010.        the  address  is  a version-4 IP address, with a length of 4  octets 
  1011.  
  1012.      X'03' 
  1013.  
  1014.        the address field contains a  DNS-style  domain  name.  The  first 
  1015.       octet  of  the  address  field contains the number of  octets that 
  1016.       follow. 
  1017.  
  1018.      X'04' 
  1019.  
  1020.        the address is a version-6 IP address, with a length  of  16  octets. 
  1021.  
  1022.   Address resolution proxy: Because of the protocol limitation, Version 4 based 
  1023.  SOCKS servers require full DNS support to be operational (every SOCKS V4 
  1024.  client must be able to resolve all the accessible destination addresses). 
  1025.  The built-in address resolution proxy in Version 5 based SOCKS server will 
  1026.  enables SOCKS V5 clients to be fully operational without having DNS support. A 
  1027.  SOCKS client can pass the name, instead of resolved address, to the SOCKS 
  1028.  server and the server will resolve the address for the client. 
  1029.  
  1030.  
  1031. ΓòÉΓòÉΓòÉ 13.5. Replies ΓòÉΓòÉΓòÉ
  1032.  
  1033.  
  1034.  The  SOCKS request information is sent by the client as soon  as it has 
  1035. established a connection to the SOCKS server,  and  completed the 
  1036. authentication negotiations.  The server  evaluates the request, and returns a 
  1037. reply formed as follows: 
  1038.  
  1039.  
  1040.   +----+-----+-------+------+----------+----------+
  1041.   |VER | REP |  RSV  | ATYP | BND.ADDR | BND.PORT |
  1042.   +----+-----+-------+------+----------+----------+
  1043.   | 1  |  1  | X'00' |  1   | Variable |    2     |
  1044.   +----+-----+-------+------+----------+----------+
  1045.  Where:
  1046.  
  1047.  
  1048.    o  VER    protocol version: X'05'
  1049.    o  REP    Reply field:
  1050.       o  X'00' succeeded
  1051.       o  X'01' general SOCKS server failure
  1052.       o  X'02' connection not allowed by ruleset
  1053.       o  X'03' Network unreachable
  1054.       o  X'04' Host unreachable
  1055.       o  X'05' Connection refused
  1056.       o  X'06' TTL expired
  1057.       o  X'07' Command not supported
  1058.       o  X'08' Address type not supported
  1059.       o  X'09' to X'FF' unassigned
  1060.    o  RSV    RESERVED
  1061.    o  ATYP   address type of following address
  1062.       o  IP V4 address: X'01'
  1063.       o  DOMAINNAME: X'03'
  1064.       o  IP V6 address: X'04'
  1065.    o  BND.ADDR       server bound address
  1066.    o  BND.PORT       server bound port in network octet order
  1067.  
  1068.   Fields marked RESERVED (RSV) must be set to X'00'.
  1069.  
  1070.  If the chosen method includes encapsulation for purposes  of  authentication, 
  1071. integrity  and/or  confidentiality,  the  replies are encapsulated in the 
  1072. method-dependent  encapsulation. 
  1073.  
  1074.  CONNECT 
  1075.  
  1076.  In the reply to a CONNECT, BND.PORT contains the port number  that the server 
  1077. assigned to  connect  to  the  target  host,  while BND.ADDR contains the 
  1078. associated IP address.  The supplied  BND.ADDR is often different from the IP 
  1079. address  that  the  client  uses  to  reach  the  SOCKS  server, since such 
  1080. servers are often multi-homed.  It  is  expected  that  the  SOCKS server will 
  1081. use DST.ADDR and DST.PORT, and the client-  side source address and port in 
  1082. evaluating the  CONNECT  request. 
  1083.  
  1084.  BIND 
  1085.  
  1086.  The  BIND  request  is  used  in protocols which require the  client to accept 
  1087. connections from  the  server.  FTP  is  a  well-known  example, which uses the 
  1088. primary client-to-server  connection for commands and status reports, but  may 
  1089. use  a  server-to-client  connection for transferring data on demand  (e.g. LS, 
  1090. GET, PUT). 
  1091.  
  1092.  It is expected that the client side of an application protocol  will  use  the 
  1093. BIND request only to establish secondary  connections after a primary 
  1094. connection is established  using  CONNECT.  In  is  expected  that  a  SOCKS 
  1095. server will use  DST.ADDR and DST.PORT in evaluating the BIND request. 
  1096.  
  1097.  Two replies are sent from the SOCKS  server  to  the  client  during a BIND 
  1098. operation.  The first is sent after the server  creates and binds a new socket. 
  1099. The BND.PORT field contains  the port number that the SOCKS server assigned to 
  1100. listen for  an incoming connection.  The BND.ADDR field contains the 
  1101. associated  IP  address.  The client will typically use these  pieces of 
  1102. information to notify (via the primary or  control  connection)  the 
  1103. application  server  of the rendezvous address.  The second reply occurs only 
  1104. after  the  anticipated  incoming connection succeeds or fails. 
  1105.  
  1106.  In  the  second reply, the BND.PORT and BND.ADDR fields contain  the address 
  1107. and port number of the connecting host. 
  1108.  
  1109.  UDP ASSOCIATE 
  1110.  
  1111.  The UDP ASSOCIATE request is used to establish  an  association  within  the 
  1112. UDP relay process to handle UDP datagrams.  The DST.ADDR and DST.PORT fields 
  1113. contain  the  address  and  port that the client expects to use to send UDP 
  1114. datagrams on  for the association.  The server MAY use this information to 
  1115. limit  access  to  the association.  If the client is not in  possesion of the 
  1116. information at the time of the UDP  ASSOCIATE,  the  client  MUST use a port 
  1117. number and address of all  zeros. 
  1118.  
  1119.  A UDP association terminates when the  TCP  connection  that  the UDP 
  1120. ASSOCIATE request arrived on terminates. 
  1121.  
  1122.  In  the  reply  to a UDP ASSOCIATE request, the BND.PORT and  BND.ADDR fields 
  1123. indicate the port number/address  where  the  client MUST send UDP request 
  1124. messages to be relayed. 
  1125.  
  1126.  Reply Processing 
  1127.  
  1128.  When  a reply (REP value other than X'00') indicates a failure,  the SOCKS 
  1129. server  MUST  terminate  the  TCP  connection  shortly  after sending the 
  1130. reply.  This must be no more than  10 seconds after detecting the condition 
  1131. that caused a failure. 
  1132.  
  1133.  If  the reply code (REP value of X'00') indicates a success,  and the request 
  1134. was either a BIND or a CONNECT,  the  client  may  now start passing data.  If 
  1135. the selected authentication  method supports encapsulation for the purposes of 
  1136. integrity,  authentication and/or confidentiality, the data are encapsulated 
  1137. using the method-dependent encapsulation.  Similarly,  when  data  arrives  at 
  1138. the SOCKS server for the client, the  server MUST encapsulate the data as 
  1139. appropriate for the  authentication method in use. 
  1140.  
  1141.  Procedure for UDP-based clients 
  1142.  
  1143.  A  UDP-based client MUST send its datagrams to the UDP relay  server at the 
  1144. UDP port indicated by BND.PORT in the reply to  the  UDP  ASSOCIATE request. 
  1145. If the selected authentication  method provides encapsulation for the purposes 
  1146. of authenticity,  integrity, and/or confidentiality, the datagram MUST be 
  1147. encapsulated using the appropriate encapsulation.  Each  UDP  datagram carries 
  1148. a UDP request header with it: 
  1149.  
  1150.      +----+------+------+----------+----------+----------+
  1151.      |RSV | FRAG | ATYP | DST.ADDR | DST.PORT |   DATA   |
  1152.      +----+------+------+----------+----------+----------+
  1153.      | 2  |  1   |  1   | Variable |    2     | Variable |
  1154.      +----+------+------+----------+----------+----------+
  1155.  The fields in the UDP request header are:
  1156.  
  1157.       o  RSV  Reserved X'0000'
  1158.       o  FRAG    Current fragment number
  1159.       o  ATYP    address type of following addresses:
  1160.          o  IP V4 address: X'01'
  1161.          o  DOMAINNAME: X'03'
  1162.          o  IP V6 address: X'04'
  1163.       o  DST.ADDR       desired destination address
  1164.       o  DST.PORT       desired destination port
  1165.       o  DATA     user data
  1166.  
  1167.  When  a UDP relay server decides to relay a UDP datagram, it  does so 
  1168. silently, without any notification to the requesting  client.  Similarly, it 
  1169. will drop datagrams it cannot or will  not relay.  When a UDP relay server 
  1170. receives a  reply  datagram  from  a remote host, it MUST encapsulate that 
  1171. datagram  using the above UDP request header, and any  authentication- 
  1172. method-dependent encapsulation. 
  1173.  
  1174.  The  UDP relay server MUST acquire from the SOCKS server the  expected IP 
  1175. address of the client that will  send  datagrams  to  the  BND.PORT  given  in 
  1176. the reply to UDP ASSOCIATE.  It  MUST drop any datagrams arriving from any 
  1177. source IP  address  other  than the one recorded for the particular 
  1178. association. 
  1179.  
  1180.  The FRAG field indicates whether or not this datagram is one  of  a  number 
  1181. of fragments.  If implemented, the high-order  bit indicates end-of-fragment 
  1182. sequence,  while  a  value  of  X'00'  indicates  that  this datagram is 
  1183. standalone.  Values  between 1 and 127 indicate the fragment  position  within 
  1184. a  fragment  sequence.  Each  receiver  will have a REASSEMBLY  QUEUE and a 
  1185. REASSEMBLY TIMER  associated  with  these  fragments.  The  reassembly queue 
  1186. must be reinitialized and the  associated fragments abandoned whenever the 
  1187. REASSEMBLY TIMER  expires,  or  a  new  datagram arrives carrying a FRAG field 
  1188. whose value is less than the highest  FRAG  value  processed  for this fragment 
  1189. sequence.  The reassembly timer MUST be no  less than 5 seconds.  It is 
  1190. recommended  that  fragmentation  be avoided by applications wherever possible. 
  1191.  
  1192.  Implementation  of fragmentation is optional; an implementation  that does not 
  1193. support fragmentation MUST drop any datagram  whose FRAG field is other than 
  1194. X'00'. 
  1195.  
  1196.  The  programming interface for a SOCKS-aware UDP MUST report  an available 
  1197. buffer space for UDP datagrams that is  smaller  than the actual space provided 
  1198. by the operating system: 
  1199.  
  1200.  
  1201.   o  if ATYP is X'01' - 10+method_dependent octets smaller
  1202.   o  if ATYP is X'03' - 262+method_dependent octets smaller
  1203.   o  if ATYP is X'04' - 20+method_dependent octets smaller
  1204.  
  1205.  
  1206. ΓòÉΓòÉΓòÉ 13.6. Security Considerations ΓòÉΓòÉΓòÉ
  1207.  
  1208.  
  1209.  This document describes a protocol for the application-layer  traversal of IP 
  1210. network firewalls.  The  security  of  such  traversal  is highly dependent on 
  1211. the particular authentication  and encapsulation methods provided in a 
  1212. particular  implementation,  and selected during negotiation between SOCKS 
  1213. client and SOCKS server. 
  1214.  
  1215.  Careful consideration should be given by  the  administrator  to the selection 
  1216. of authentication methods. 
  1217.  
  1218.  Authors Address 
  1219.  
  1220.   Marcus Leech
  1221.   Bell-Northern Research
  1222.   P.O. Box 3511, Stn. C,
  1223.   Ottawa, ON
  1224.   CANADA K1Y 4H7
  1225.  
  1226.   Email: mleech@bnr.ca
  1227.  
  1228.  
  1229. ΓòÉΓòÉΓòÉ 13.7. Username/Password Authentication for SOCKS V5 ΓòÉΓòÉΓòÉ
  1230.  
  1231.  Username/Password Authentication for SOCKS V5 
  1232.  
  1233. Network Working Group                         M. Leech
  1234. Request for Comments: 1929  Bell-Northern Research Ltd
  1235. Category: Standards Track                   March 1996
  1236.  
  1237.  Status of this Memo 
  1238.  
  1239.  This document specifies an Internet standards track protocol for the  Internet 
  1240. community, and requests discussion and suggestions for  improvements.  Please 
  1241. refer to the current edition of the "Internet  Official Protocol Standards" 
  1242. (STD 1) for the standardization state  and status of this protocol. 
  1243. Distribution of this memo is unlimited. 
  1244.  
  1245.  Introduction 
  1246.  
  1247.  The protocol specification for SOCKS Version 5 specifies a  generalized 
  1248. framework for the use of arbitrary authentication  protocols in the initial 
  1249. socks connection setup. This document  describes one of those protocols, as it 
  1250. fits into the SOCKS Version 5  authentication "subnegotiation". 
  1251. Note: 
  1252.  
  1253.  Unless otherwise noted, the decimal numbers appearing in packet-  format 
  1254. diagrams represent the length of the corresponding field, in  octets.  Where a 
  1255. given octet must take on a specific value, the  syntax X'hh' is used to denote 
  1256. the value of the single octet in that  field. When the word 'Variable' is used, 
  1257. it indicates that the  corresponding field has a variable length defined either 
  1258. by an  associated (one or two octet) length field, or by a data type field. 
  1259.  
  1260.  Initial negotiation 
  1261.  
  1262.  Once the SOCKS V5 server has started, and the client has selected the 
  1263. Username/Password Authentication protocol, the Username/Password 
  1264. subnegotiation begins.  This begins with the client producing a 
  1265. Username/Password request: 
  1266.  
  1267.  
  1268.  +----+------+----------+------+----------+
  1269.  |VER | ULEN |  UNAME   | PLEN |  PASSWD  |
  1270.  +----+------+----------+------+----------+
  1271.  | 1  |  1   | 1 to 255 |  1   | 1 to 255 |
  1272.  +----+------+----------+------+----------+
  1273.  
  1274.  
  1275.  The VER field contains the current version of the subnegotiation,  which is 
  1276. X'01'. The ULEN field contains the  length of the UNAME field that follows. The 
  1277. UNAME field  contains the username as known to the source operating  system. 
  1278. The PLEN field contains the length of the PASSWD  field that follows. The 
  1279. PASSWD field contains the pass-  word association with the given UNAME. 
  1280.  
  1281.  The server verifies the supplied UNAME and PASSWD, and  sends the following 
  1282. response: 
  1283.  
  1284.  
  1285.      +----+--------+
  1286.      |VER | STATUS |
  1287.      +----+--------+
  1288.      | 1  |   1    |
  1289.      +----+--------+
  1290.  
  1291.  A STATUS field of X'00' indicates success. If the server  returns a `failure' 
  1292. (STATUS value other than X'00') status,  it MUST close the connection. 
  1293.  
  1294.  Security Considerations 
  1295.  
  1296.  This document describes a subnegotiation that provides authentication 
  1297. services to the SOCKS protocol. Since the request carries the  password in 
  1298. cleartext, this subnegotiation is not recommended for  environments where 
  1299. "sniffing" is possible and practical. 
  1300.  
  1301.  Authors Address 
  1302.  
  1303.    Marcus Leech
  1304.    Bell-Northern Research Ltd
  1305.    P.O. Box 3511, Station C
  1306.    Ottawa, ON
  1307.    CANADA K1Y 4H7
  1308.  
  1309.    +1 613 763 9145
  1310.  
  1311.    Email: mleech@bnr.ca
  1312.  
  1313.  
  1314. ΓòÉΓòÉΓòÉ 14. RFC1918 : Address Allocation for Private Internets ΓòÉΓòÉΓòÉ
  1315.  
  1316. Network Working Group                               Y. Rekhter
  1317. Request for Comments: 1918                       Cisco Systems
  1318. Obsoletes: 1627, 1597                             B. Moskowitz
  1319. BCP: 5                                          Chrysler Corp.
  1320. Category: Best Current Practice                  D. Karrenberg
  1321.                                                       RIPE NCC
  1322.                                                 G. J. de Groot
  1323.                                                       RIPE NCC
  1324.                                                        E. Lear
  1325.                                         Silicon Graphics, Inc.
  1326.                                                  February 1996
  1327.  
  1328.  
  1329. ΓòÉΓòÉΓòÉ 14.1. Status of this Memo ΓòÉΓòÉΓòÉ
  1330.  
  1331.  
  1332.  This document specifies an Internet Best Current Practices for the  Internet 
  1333. Community, and requests discussion and suggestions for  improvements. 
  1334. Distribution of this memo is unlimited. 
  1335.  
  1336.  
  1337. ΓòÉΓòÉΓòÉ 14.2. Introduction ΓòÉΓòÉΓòÉ
  1338.  
  1339.  
  1340.  For the purposes of this document, an enterprise is an entity  autonomously 
  1341. operating a network using TCP/IP and in particular  determining the addressing 
  1342. plan and address assignments within that  network. 
  1343.  
  1344.  This document describes address allocation for private internets. The 
  1345. allocation permits full network layer connectivity among all hosts  inside an 
  1346. enterprise as well as among all public hosts of different  enterprises. The 
  1347. cost of using private internet address space is the  potentially costly effort 
  1348. to renumber hosts and networks between  public and private. 
  1349.  
  1350.  
  1351. ΓòÉΓòÉΓòÉ 14.3. Motivation ΓòÉΓòÉΓòÉ
  1352.  
  1353.  
  1354.  With the proliferation of TCP/IP technology worldwide, including  outside the 
  1355. Internet itself, an increasing number of non-connected  enterprises use this 
  1356. technology and its addressing capabilities for  sole intra-enterprise 
  1357. communications, without any intention to ever  directly connect to other 
  1358. enterprises or the Internet itself. 
  1359.  
  1360.  The Internet has grown beyond anyone's expectations. Sustained  exponential 
  1361. growth continues to introduce new challenges.  One  challenge is a concern 
  1362. within the community that globally unique  address space will be exhausted. A 
  1363. separate and far more pressing  concern is that the amount of routing overhead 
  1364. will grow beyond the  capabilities of Internet Service Providers. Efforts are 
  1365. in progress  within the community to find long term solutions to both of these 
  1366. problems. Meanwhile it is necessary to revisit address allocation  procedures, 
  1367. and their impact on the Internet routing system. 
  1368.  
  1369.  To contain growth of routing overhead, an Internet Provider obtains a  block 
  1370. of address space from an address registry, and then assigns to  its customers 
  1371. addresses from within that block based on each customer  requirement. The 
  1372. result of this process is that routes to many  customers will be aggregated 
  1373. together, and will appear to other  providers as a single route ΓòÆRFC1518Γûá, 
  1374. ΓòÆRFC1519Γûá.  In order for route  aggregation to be effective, Internet providers 
  1375. encourage customers  joining their network to use the provider's block, and 
  1376. thus renumber  their computers. Such encouragement may become a requirement in 
  1377. the  future. 
  1378.  
  1379.  With the current size of the Internet and its growth rate it is no  longer 
  1380. realistic to assume that by virtue of acquiring globally  unique IP addresses 
  1381. out of an Internet registry an organization that  acquires such addresses would 
  1382. have Internet-wide IP connectivity once  the organization gets connected to the 
  1383. Internet. To the contrary, it  is quite likely that when the organization would 
  1384. connect to the  Internet to achieve Internet-wide IP connectivity the 
  1385. organization  would need to change IP addresses (renumber) all of its public 
  1386. hosts  (hosts that require Internet-wide IP connectivity), regardless of 
  1387. whether the addresses used by the organization initially were  globally unique 
  1388. or not. 
  1389.  
  1390.  It has been typical to assign globally unique addresses to all hosts  that use 
  1391. TCP/IP. In order to extend the life of the IPv4 address  space, address 
  1392. registries are requiring more justification than ever  before, making it harder 
  1393. for organizations to acquire additional  address space ΓòÆRFC1466Γûá. 
  1394.  
  1395.  Hosts within enterprises that use IP can be partitioned into three 
  1396. categories: 
  1397.  
  1398.      Category 1: hosts that do not require access to hosts in other 
  1399.       enterprises or the Internet at large; hosts within  this category may use 
  1400.       IP addresses that are  unambiguous within an enterprise, but may be 
  1401.       ambiguous between enterprises. 
  1402.  
  1403.      Category 2: hosts that need access to a limited set of outside  services 
  1404.       (e.g., E-mail, FTP, netnews, remote login)  which can be handled by 
  1405.       mediating gateways (e.g.,  application layer gateways). For many hosts in 
  1406.       this  category an unrestricted external access (provided  via IP 
  1407.       connectivity) may be unnecessary and even  undesirable for 
  1408.       privacy/security reasons. Just like  hosts within the first category, 
  1409.       such hosts may use  IP addresses that are unambiguous within an 
  1410.       enterprise, but may be ambiguous between  enterprises. 
  1411.  
  1412.      Category 3: hosts that need network layer access outside the  enterprise 
  1413.       (provided via IP connectivity); hosts in  the last category require IP 
  1414.       addresses that are  globally unambiguous. 
  1415.  
  1416.   We will refer to the hosts in the first and second categories as  "private". 
  1417.  We will refer to the hosts in the third category as  "public". 
  1418.  
  1419.   Many applications require connectivity only within one enterprise and  do not 
  1420.  need external (outside the enterprise) connectivity for the  majority of 
  1421.  internal hosts. In larger enterprises it is often easy to  identify a 
  1422.  substantial number of hosts using TCP/IP that do not need  network layer 
  1423.  connectivity outside the enterprise. 
  1424.  
  1425.   Some examples, where external connectivity might not be required,  are: 
  1426.  
  1427.      A large airport which has its arrival/departure displays  individually 
  1428.       addressable via TCP/IP. It is very unlikely  that these displays need to 
  1429.       be directly accessible from  other networks. 
  1430.  
  1431.      Large organizations like banks and retail chains are  switching to TCP/IP 
  1432.       for their internal communication. Large  numbers of local workstations 
  1433.       like cash registers, money  machines, and equipment at clerical positions 
  1434.       rarely need  to have such connectivity. 
  1435.  
  1436.      For security reasons, many enterprises use application  layer gateways to 
  1437.       connect their internal network to the  Internet.  The internal network 
  1438.       usually does not have  direct access to the Internet, thus only one or 
  1439.       more  gateways are visible from the Internet. In this case, the  internal 
  1440.       network can use non-unique IP network numbers. 
  1441.  
  1442.      Interfaces of routers on an internal network usually do not  need to be 
  1443.       directly accessible from outside the enterprise. 
  1444.  
  1445.  
  1446. ΓòÉΓòÉΓòÉ 14.4. Private Address Space ΓòÉΓòÉΓòÉ
  1447.  
  1448.  
  1449.  The Internet Assigned Numbers Authority (IANA) has reserved the  following 
  1450. three blocks of the IP address space for private internets: 
  1451.  
  1452.  
  1453.      10.0.0.0        -   10.255.255.255  (10/8 prefix)
  1454.      172.16.0.0      -   172.31.255.255  (172.16/12 prefix)
  1455.      192.168.0.0     -   192.168.255.255 (192.168/16 prefix)
  1456.  
  1457.  
  1458.  We will refer to the first block as "24-bit block", the second as  "20-bit 
  1459. block", and to the third as "16-bit" block. Note that (in  pre-CIDR notation) 
  1460. the first block is nothing but a single class A  network number, while the 
  1461. second block is a set of 16 contiguous  class B network numbers, and third 
  1462. block is a set of 256 contiguous  class C network numbers. 
  1463.  
  1464.  An enterprise that decides to use IP addresses out of the address  space 
  1465. defined in this document can do so without any coordination  with IANA or an 
  1466. Internet registry. The address space can thus be used  by many enterprises. 
  1467. Addresses within this private address space will  only be unique within the 
  1468. enterprise, or the set of enterprises which  choose to cooperate over this 
  1469. space so they may communicate with each  other in their own private internet. 
  1470.  
  1471.  As before, any enterprise that needs globally unique address space is 
  1472. required to obtain such addresses from an Internet registry. An  enterprise 
  1473. that requests IP addresses for its external connectivity  will never be 
  1474. assigned addresses from the blocks defined above. 
  1475.  
  1476.  In order to use private address space, an enterprise needs to  determine which 
  1477. hosts do not need to have network layer connectivity  outside the enterprise in 
  1478. the foreseeable future and thus could be  classified as private. Such hosts 
  1479. will use the private address space  defined above.  Private hosts can 
  1480. communicate with all other hosts  inside the enterprise, both public and 
  1481. private. However, they cannot  have IP connectivity to any host outside of the 
  1482. enterprise. While not  having external (outside of the enterprise) IP 
  1483. connectivity private  hosts can still have access to external services via 
  1484. mediating  gateways (e.g., application layer gateways). 
  1485.  
  1486.  All other hosts will be public and will use globally unique address  space 
  1487. assigned by an Internet Registry. Public hosts can communicate  with other 
  1488. hosts inside the enterprise both public and private and  can have IP 
  1489. connectivity to public hosts outside the enterprise.  Public hosts do not have 
  1490. connectivity to private hosts of other  enterprises. 
  1491.  
  1492.  Moving a host from private to public or vice versa involves a change  of IP 
  1493. address, changes to the appropriate DNS entries, and changes to  configuration 
  1494. files on other hosts that reference the host by IP  address. 
  1495.  
  1496.  Because private addresses have no global meaning, routing information  about 
  1497. private networks shall not be propagated on inter-enterprise  links, and 
  1498. packets with private source or destination addresses  should not be forwarded 
  1499. across such links. Routers in networks not  using private address space, 
  1500. especially those of Internet service  providers, are expected to be configured 
  1501. to reject (filter out)  routing information about private networks. If such a 
  1502. router receives  such information the rejection shall not be treated as a 
  1503. routing  protocol error. 
  1504.  
  1505.  Indirect references to such addresses should be contained within the 
  1506. enterprise. Prominent examples of such references are DNS Resource  Records and 
  1507. other information referring to internal private  addresses. In particular, 
  1508. Internet service providers should take  measures to prevent such leakage. 
  1509.  
  1510.  
  1511. ΓòÉΓòÉΓòÉ 14.5. Advantages and Disadvantages of Using Private Address Space ΓòÉΓòÉΓòÉ
  1512.  
  1513.  
  1514.  The obvious advantage of using private address space for the Internet  at 
  1515. large is to conserve the globally unique address space by not  using it where 
  1516. global uniqueness is not required. 
  1517.  
  1518.  Enterprises themselves also enjoy a number of benefits from their  usage of 
  1519. private address space: They gain a lot of flexibility in  network design by 
  1520. having more address space at their disposal than  they could obtain from the 
  1521. globally unique pool. This enables  operationally and administratively 
  1522. convenient addressing schemes as  well as easier growth paths. 
  1523.  
  1524.  For a variety of reasons the Internet has already encountered  situations 
  1525. where an enterprise that has not been connected to the  Internet had used IP 
  1526. address space for its hosts without getting this  space assigned from the IANA. 
  1527. In some cases this address space had  been already assigned to other 
  1528. enterprises. If such an enterprise  would later connects to the Internet, this 
  1529. could potentially create  very serious problems, as IP routing cannot provide 
  1530. correct  operations in presence of ambiguous addressing. Although in principle 
  1531. Internet Service Providers should guard against such mistakes through  the use 
  1532. of route filters, this does not always happen in practice.  Using private 
  1533. address space provides a safe choice for such  enterprises, avoiding clashes 
  1534. once outside connectivity is needed. 
  1535.  
  1536.  A major drawback to the use of private address space is that it may  actually 
  1537. reduce an enterprise's flexibility to access the Internet.  Once one commits to 
  1538. using a private address, one is committing to  renumber part or all of an 
  1539. enterprise, should one decide to provide  IP connectivity between that part (or 
  1540. all of the enterprise) and the  Internet.  Usually the cost of renumbering can 
  1541. be measured by  counting the number of hosts that have to transition from 
  1542. private to  public. As was discussed earlier, however, even if a network uses 
  1543. globally unique addresses, it may still have to renumber in order to  acquire 
  1544. Internet-wide IP connectivity. 
  1545.  
  1546.  Another drawback to the use of private address space is that it may  require 
  1547. renumbering when merging several private internets into a  single private 
  1548. internet. If we review the examples we list in Section  2, we note that 
  1549. companies tend to merge. If such companies prior to  the merge maintained their 
  1550. uncoordinated internets using private  address space, then if after the merge 
  1551. these private internets would  be combined into a single private internet, some 
  1552. addresses within the  combined private internet may not be unique. As a result, 
  1553. hosts with  these addresses would need to be renumbered. 
  1554.  
  1555.  The cost of renumbering may well be mitigated by development and  deployment 
  1556. of tools that facilitate renumbering (e.g.  Dynamic Host  Configuration 
  1557. Protocol (DHCP)). When deciding whether to use private  addresses, we recommend 
  1558. to inquire computer and software vendors  about availability of such tools.  A 
  1559. separate IETF effort (PIER  Working Group) is pursuing full documentation of 
  1560. the requirements and  procedures for renumbering. 
  1561.  
  1562.  
  1563. ΓòÉΓòÉΓòÉ 14.6. Operational Considerations ΓòÉΓòÉΓòÉ
  1564.  
  1565.  
  1566.  One possible strategy is to design the private part of the network  first and 
  1567. use private address space for all internal links. Then plan  public subnets at 
  1568. the locations needed and design the external  connectivity. 
  1569.  
  1570.  This design does not need to be fixed permanently. If a group of one  or more 
  1571. hosts requires to change their status (from private to public  or vice versa) 
  1572. later, this can be accomplished by renumbering only  the hosts involved, and 
  1573. changing physical connectivity, if needed. In  locations where such changes can 
  1574. be foreseen (machine rooms, etc.),  it is advisable to configure separate 
  1575. physical media for public and  private subnets to facilitate such changes.  In 
  1576. order to avoid major  network disruptions, it is advisable to group hosts with 
  1577. similar  connectivity needs on their own subnets. 
  1578.  
  1579.  If a suitable subnetting scheme can be designed and is supported by  the 
  1580. equipment concerned, it is advisable to use the 24-bit block  (class A network) 
  1581. of private address space and make an addressing  plan with a good growth path. 
  1582. If subnetting is a problem, the 16-bit  block (class C networks), or the 20-bit 
  1583. block (class B networks) of  private address space can be used. 
  1584.  
  1585.  One might be tempted to have both public and private addresses on the  same 
  1586. physical medium. While this is possible, there are pitfalls to  such a design 
  1587. (note that the pitfalls have nothing to do with the use  of private addresses, 
  1588. but are due to the presence of multiple IP  subnets on a common Data Link 
  1589. subnetwork).  We advise caution when  proceeding in this area. 
  1590.  
  1591.  It is strongly recommended that routers which connect enterprises to  external 
  1592. networks are set up with appropriate packet and routing  filters at both ends 
  1593. of the link in order to prevent packet and  routing information leakage. An 
  1594. enterprise should also filter any  private networks from inbound routing 
  1595. information in order to protect  itself from ambiguous routing situations which 
  1596. can occur if routes to  the private address space point outside the enterprise. 
  1597.  
  1598.  It is possible for two sites, who both coordinate their private  address 
  1599. space, to communicate with each other over a public network.  To do so they 
  1600. must use some method of encapsulation at their borders  to a public network, 
  1601. thus keeping their private addresses private. 
  1602.  
  1603.  If two (or more) organizations follow the address allocation  specified in 
  1604. this document and then later wish to establish IP  connectivity with each 
  1605. other, then there is a risk that address  uniqueness would be violated.  To 
  1606. minimize the risk it is strongly  recommended that an organization using 
  1607. private IP addresses choose  randomly from the reserved pool of private 
  1608. addresses, when allocating  sub-blocks for its internal allocation. 
  1609.  
  1610.  If an enterprise uses the private address space, or a mix of private  and 
  1611. public address spaces, then DNS clients outside of the enterprise  should not 
  1612. see addresses in the private address space used by the  enterprise, since these 
  1613. addresses would be ambiguous.  One way to  ensure this is to run two authority 
  1614. servers for each DNS zone  containing both publically and privately addressed 
  1615. hosts.  One server  would be visible from the public address space and would 
  1616. contain only  the subset of the enterprise's addresses which were reachable 
  1617. using  public addresses.  The other server would be reachable only from the 
  1618. private network and would contain the full set of data, including the  private 
  1619. addresses and whatever public addresses are reachable the  private network.  In 
  1620. order to ensure consistency, both servers should  be configured from the same 
  1621. data of which the publically visible zone  only contains a filtered version. 
  1622. There is certain degree of  additional complexity associated with providing 
  1623. these capabilities. 
  1624.  
  1625.  
  1626. ΓòÉΓòÉΓòÉ 14.7. Security Considerations ΓòÉΓòÉΓòÉ
  1627.  
  1628.  
  1629.  Security issues are not addressed in this memo. 
  1630.  
  1631.  
  1632. ΓòÉΓòÉΓòÉ 14.8. Conclusion ΓòÉΓòÉΓòÉ
  1633.  
  1634.  
  1635.  With the described scheme many large enterprises will need only a  relatively 
  1636. small block of addresses from the globally unique IP  address space. The 
  1637. Internet at large benefits through conservation of  globally unique address 
  1638. space which will effectively lengthen the  lifetime of the IP address space. 
  1639. The enterprises benefit from the  increased flexibility provided by a 
  1640. relatively large private address  space. However, use of private addressing 
  1641. requires that an  organization renumber part or all of its enterprise network, 
  1642. as its  connectivity requirements change over time. 
  1643.  
  1644.  
  1645. ΓòÉΓòÉΓòÉ 14.9. Acknowledgments ΓòÉΓòÉΓòÉ
  1646.  
  1647.  
  1648.  We would like to thank Tony Bates (MCI), Jordan Becker (ANS), Hans-  Werner 
  1649. Braun (SDSC), Ross Callon (BayNetworks), John Curran (BBN  Planet), Vince 
  1650. Fuller (BBN Planet), Tony Li (cisco Systems), Anne  Lord (RIPE NCC), Milo Medin 
  1651. (NSI), Marten Terpstra (BayNetworks),  Geza Turchanyi (RIPE NCC), Christophe 
  1652. Wolfhugel (Pasteur Institute),  Andy Linton (connect.com.au), Brian Carpenter 
  1653. (CERN), Randy Bush  (PSG), Erik Fair (Apple Computer), Dave Crocker 
  1654. (Brandenburg  Consulting), Tom Kessler (SGI), Dave Piscitello (Core 
  1655. Competence),  Matt Crawford (FNAL), Michael Patton (BBN), and Paul Vixie 
  1656. (Internet  Software Consortium) for their review and constructive comments. 
  1657.  
  1658.  
  1659. ΓòÉΓòÉΓòÉ 15. If problems ΓòÉΓòÉΓòÉ
  1660.  
  1661.      The DNS kit nameD server can block if the system is fully "socksified". 
  1662.       Don't hesitate to rename the "socks.cfg" file in the ETC directory when 
  1663.       you are running sockD. 
  1664.  
  1665.      If your configuration is limited to one LAN adapter and one dial adapter, 
  1666.       it is better to test sockd without configuring it... Use the view menu 
  1667.       option to see the config. After tests, check sockd.log ... 
  1668.  
  1669.      If you have really a problem to setup a name server on the gateway 
  1670.       station, define a "hosts" file. For that, when you are testing your 
  1671.       "sockdial.cmd" after the connection and authentication are successfully 
  1672.       completed, use : 
  1673.        host www.yahoo.com 
  1674.       in an OS/2 Window. You are able to get the IP addresses of your favorite 
  1675.       servers. If you install a "completed" hosts file in the ETC directory of 
  1676.       the end-user PC you can test sockd with WebEx (socks V4) without setting 
  1677.       a name server. With a name server and its caching mechanism, you have 
  1678.       access to any server, with the hosts file access is limited... 
  1679.  
  1680.      To support socks V5 DNS, the dial-up connection is started automatically 
  1681.       if the name can NOT be locally traduced... A better solution is perhaps 
  1682.       to define a list of the "internal" domain names, and to start the 
  1683.       connection only if the request is for another domain name. On the time 
  1684.       being, sockd start the dial-up connection for V5, before checking if the 
  1685.       connection is "permitted" except if the DNS name can be locally traduced. 
  1686.       With the current implementation: - in socks V4 the first session (to 
  1687.       start the dial-up connection) MUST be  to a "locally" defined DNS name 
  1688.       (then sockd check if the client has access  to this address before 
  1689.       starting the connection). - in V5 DNS support, the first session can be 
  1690.       to any DNS name, but if this  name can NOT be locally translatted, there 
  1691.       a delay (nearly 1 min. in my tests)  then the dial-up connection is 
  1692.       started and the DNS name translation request  is sent to the "external" 
  1693.       name server.  The "permission" can be checked only after sockd received 
  1694.       the destination  IP address. 
  1695.  
  1696.      In this version , only the flags "811" (<UP,POINTTOPOINT>) or "851" 
  1697.       (<..,RUNNING>) are considered as "good" status (connection established) 
  1698.       on the dial-up adapter. If the "auto-dial" facility doesn't work for you, 
  1699.       please check these flags with: 
  1700.       "ifconfig ppp0" (by sample) 
  1701.       Send a note to me and I'll add the required support... 
  1702.  
  1703.      With current V4 applications like WebEx, the first session must be done 
  1704.       to a DNS name converted locally (named or hosts file). After the dial-up 
  1705.       connection is established, names can be translatted by the Internet 
  1706.       provider name server, and cached in the local nameD. 
  1707.  
  1708.      Using WebEx through sockd, some ".gif" files are not correctly received I 
  1709.       am investigating why and how to improve it. 
  1710.  
  1711.  
  1712.   Any suggestion or question to Philippe Gillain (GILLAIN at BRUVMIS1 or 
  1713.  Philippe_Gillain@be.ibm.com)...